--fdj2RfSjLxBAspz7
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Moin,

ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
und was in pg_class steht, und ich pg_constraint ist das offensichtlich
falsch, also ich würde es als Bug sehen. Was meint ihr?

(Problem nachvollzogen mit 8.1.4)


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

--fdj2RfSjLxBAspz7
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <cyrus [at] webserv>
Received: from webserv ([unix socket])
by webserv (Cyrus v2.1.18-IPv6-Debian-2.1.18-1+sarge2) with LMTP; Thu, 19 Mar 2009 10:50:29 +0100
X-Sieve: CMU Sieve 2.2
Received: from amavis by webserv.wug.de with scanned-ok (Exim 3.36 #1)
id 1LkEtR-0000NF-00
for kretschmer [at] localhost; Thu, 19 Mar 2009 10:50:29 +0100
Received: from webserv.wug.de ([127.0.0.1])
by localhost (webserv [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 00693-08 for <kretschmer [at] localhost>;
Thu, 19 Mar 2009 10:50:07 +0100 (CET)
Received: from localhost ([127.0.0.1] ident=root)
by webserv.wug.de with esmtp (Exim 3.36 #1)
id 1LkEt5-0000Mp-01
for kretschmer [at] localhost; Thu, 19 Mar 2009 10:50:07 +0100
Received: from pop.1und1.com [212.227.15.177]
by localhost with POP3 (fetchmail-6.2.5)
for kretschmer [at] localhost (single-drop); Thu, 19 Mar 2009 10:50:07 +0100 (CET)
Received: from ssl.schlittermann.de (pu.schlittermann.de [212.80.235.130])
by mx.kundenserver.de (node=mxeu3) with ESMTP (Nemesis)
id 0MKqIe-1LkEpF1rl2-0008RC ; Thu, 19 Mar 2009 10:46:09 +0100
Received: from localhost ([127.0.0.1]:53039 helo=pu.schlittermann.de)
by ssl.schlittermann.de with esmtp (Exim 4.68)
(envelope-from <lug-dd-bounces [at] mailman.schlittermann.de>)
id 1LkEpE-0006fu-Td; Thu, 19 Mar 2009 10:46:09 +0100
Received: from uucp by ssl.schlittermann.de with local-rmail (Exim 4.68)
(envelope-from <hs [at] schlittermann.de>) id 1LkEot-0006eo-Ax
for lug-dd [at] mailman.schlittermann.de; Thu, 19 Mar 2009 10:45:47 +0100
Received: from heiko by jumper with local (Exim 4.69)
(envelope-from <hs [at] schlittermann.de>) id 1LkEoJ-0004hH-6h
for Lug-dd [at] mailman.schlittermann.de; Thu, 19 Mar 2009 10:45:11 +0100
Date: Thu, 19 Mar 2009 10:45:11 +0100
From: Heiko Schlittermann <hs [at] schlittermann.de>
To: Lug-dd <Lug-dd [at] mailman.schlittermann.de>
Message-ID: <20090319094511.GF11937 [at] jumper>
Mail-Followup-To: Lug-dd <Lug-dd [at] mailman.schlittermann.de>
MIME-Version: 1.0
X-Phone: +49.172.7909055 / SMS welcome
Organization: schlittermann -- internet & unix support
User-Agent: Mutt/1.5.18 (2008-05-17)
X-BeenThere: lug-dd [at] mailman.schlittermann.de
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Linux-User-Group Dresden <lug-dd [at] mailman.schlittermann.de>
List-Id: Linux-User-Group Dresden <lug-dd.mailman.schlittermann.de>
List-Unsubscribe: <https://ssl.schlittermann.de/mailman/listinfo/lug-dd>,
<mailto:lug-dd-request [at] mailman.schlittermann.de?subject=unsubscribe>
List-Archive: <http://ssl.schlittermann.de/pipermail/lug-dd>
List-Post: <mailto:lug-dd [at] mailman.schlittermann.de>
List-Help: <mailto:lug-dd-request [at] mailman.schlittermann.de?subject=help>
List-Subscribe: <https://ssl.schlittermann.de/mailman/listinfo/lug-dd>,
<mailto:lug-dd-request [at] mailman.schlittermann.de?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1256415066=="
Mime-version: 1.0
Sender: lug-dd-bounces [at] mailman.schlittermann.de
Errors-To: lug-dd-bounces [at] mailman.schlittermann.de
Subject: PostgreSQL 8.1.11: pg_dump =?utf-8?Q?wei?=
=?utf-8?B?w58=?= nichts von umbenannten Indizes?
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at schollglas.com


--===============1256415066==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="11Y7aswkeuHtSBEs"
Content-Disposition: inline


--11Y7aswkeuHtSBEs
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hallo,

es gibt ja hier den einen oder anderen, der PostgreSQL macht.
Ich habe da etwas, was ich f=C3=BCr komisch halte. Es handelt sich um 8.1.11
als Server - ist nicht mehr das Neueste, ich wei=C3=9F, aber es ist ein SLES
und da mu=C3=9F es super sein ...

psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT);
psql> \d+ a1
Column | Type | Modifiers | De=
scription
--------+--------+------------------------------------------ -------+---=
----------
id | bigint | not null default nextval('a1_id_seq'::regclass) |
name | text | |
Indexes:
"a1_pkey" PRIMARY KEY, btree (id)
Has OIDs: no


Wenn ich das per pg_dump ausspucke, kommt da erwartungsgem=C3=A4=C3=9F die=

Table-Definition und dann im Dump noc hein ein

ALTER TABLE ONLY a1 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);

Soweit so gut.

Jetzt habe ich die Tabelle und auch den Index umbenannt:

psql> ALTER TABLE a1 RENAME TO a2;
psql> ALTER INDEX a1_pkey RENAME TO a2_pkey;
psql> \d+ a2
Column | Type | Modifiers | De=
scription
--------+--------+------------------------------------------ -------+---=
----------
id | bigint | not null default nextval('a1_id_seq'::regclass) |
name | text | |
Indexes:
"a2_pkey" PRIMARY KEY, btree (id)
Has OIDs: no

Sieht auch noch gut aus, Tabelle und Index haben neue Namen.
Jetzt aber im pg_dump, erscheint immer noch

ALTER TABLE ONLY a2 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);

Und mein a2_pkey wird nirgens erw=C3=A4hnt.

Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es
nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6)
nehme, dann ist das genauso falsch, au=C3=9Fer ich mache das o.a. Experiment
auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet h=C3=A4tte.


Viele Gr=C3=BC=C3=9Fe
Heiko
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann HS12-RIPE -----------------------------------------
gnupg encrypted messages are welcome - key ID: 48D0359B ---------------
gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B -

--11Y7aswkeuHtSBEs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknCFCcACgkQ7k6smEjQNZvSVgCeK3WTzZhY2zgQ3GOBPTE6 3z3H
1V0AoLmNJxt4wa6UHA6LVitMvrkjofbA
=OfTN
-----END PGP SIGNATURE-----

--11Y7aswkeuHtSBEs--



--===============1256415066==
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

_______________________________________________
Lug-dd maillist - Lug-dd [at] mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd=

--===============1256415066==--




--fdj2RfSjLxBAspz7
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

--fdj2RfSjLxBAspz7--

A. Kretschmer wrote:
> Moin,
>
> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constrain=
t
> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
> falsch, also ich w=C3=BCrde es als Bug sehen. Was meint ihr?
>
> (Problem nachvollzogen mit 8.1.4)

Vorneweg: in 8.3 geht es richtig.

Das Problem ist aber, dass er den Index umbenannt hat und nicht den
Constraint. Der Index wurde ja automatisch als Implementierungsdetail
des Constraints angelegt. Korrekt w=C3=A4re also entweder das direkte
Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher,
wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.

>
>
> Andreas
>
>
> ------------------------------------------------------------ -----------=
-
>
> Subject:
> PostgreSQL 8.1.11: pg_dump wei=C3=9F nichts von umbenannten Indizes?
> From:
> Heiko Schlittermann <hs [at] schlittermann.de>
> Date:
> Thu, 19 Mar 2009 10:45:11 +0100
> To:
> Lug-dd <Lug-dd [at] mailman.schlittermann.de>
>
> To:
> Lug-dd <Lug-dd [at] mailman.schlittermann.de>
>
>
> Hallo,
>
> es gibt ja hier den einen oder anderen, der PostgreSQL macht.
> Ich habe da etwas, was ich f=C3=BCr komisch halte. Es handelt sich um 8=
..1.11
> als Server - ist nicht mehr das Neueste, ich wei=C3=9F, aber es ist ein=
SLES
> und da mu=C3=9F es super sein ...
>
> psql> CREATE TABLE a1 (id BIGSERIAL PRIMARY KEY, name TEXT);
> psql> \d+ a1
> Column | Type | Modifiers =
| Description
> --------+--------+------------------------------------------ -------=
+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) =
|
> name | text | =
|
> Indexes:
> "a1_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>
>
> Wenn ich das per pg_dump ausspucke, kommt da erwartungsgem=C3=A4=C3=9F =
die
> Table-Definition und dann im Dump noc hein ein
>
> ALTER TABLE ONLY a1 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>
> Soweit so gut.
>
> Jetzt habe ich die Tabelle und auch den Index umbenannt:
>
> psql> ALTER TABLE a1 RENAME TO a2;
> psql> ALTER INDEX a1_pkey RENAME TO a2_pkey;
> psql> \d+ a2
> Column | Type | Modifiers =
| Description
> --------+--------+------------------------------------------ -------=
+-------------
> id | bigint | not null default nextval('a1_id_seq'::regclass) =
|
> name | text | =
|
> Indexes:
> "a2_pkey" PRIMARY KEY, btree (id)
> Has OIDs: no
>
> Sieht auch noch gut aus, Tabelle und Index haben neue Namen.
> Jetzt aber im pg_dump, erscheint immer noch
>
> ALTER TABLE ONLY a2 ADD CONSTRAINT a1_pkey PRIMARY KEY (id);
>
> Und mein a2_pkey wird nirgens erw=C3=A4hnt.
>
> Bug oder Feature? Oder mache ich etwas falsch? Am "pg_dump" scheint es
> nicht zu liegen, wenn ich auf einer anderen Maschine ein pg_dump (8.3.6=
)
> nehme, dann ist das genauso falsch, au=C3=9Fer ich mache das o.a. Exper=
iment
> auch mit dem 8.3.6 Server, dann ist es, wie ich's erwartet h=C3=A4tte.
>
>
> Viele Gr=C3=BC=C3=9Fe
> Heiko
>
>
> ------------------------------------------------------------ -----------=
-
>
> _______________________________________________
> Lug-dd maillist - Lug-dd [at] mailman.schlittermann.de
> https://ssl.schlittermann.de/mailman/listinfo/lug-dd
>
>
> ------------------------------------------------------------ -----------=
-
>
>


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

--ZmZU9S7l/XJx5q9b
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Peter Eisentraut <peter_e [at] gmx.net> (Do 19 M=C3=A4r 2009 13:45:38 CET):
> A. Kretschmer wrote:
>> Moin,
>>
>> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
>> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
>> falsch, also ich w=C3=BCrde es als Bug sehen. Was meint ihr?
>>
>> (Problem nachvollzogen mit 8.1.4)
>
> Vorneweg: in 8.3 geht es richtig.
>
> Das Problem ist aber, dass er den Index umbenannt hat und nicht den
> Constraint. Der Index wurde ja automatisch als Implementierungsdetail
> des Constraints angelegt. Korrekt w=C3=A4re also entweder das direkte
> Umbenennen des Index zu verhindern, oder -- etwas menschenfreundlicher, =

> wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen.
>

Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), w=C3=A4re
der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und dann
ein "ALTER TABLE <table> ADD <table_constraint>" ?


--
Heiko

--ZmZU9S7l/XJx5q9b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknCQlwACgkQ7k6smEjQNZteJACglfuaxkgfFvfEIUlakAy/ dlsv
uboAoIHTzegbJKzRx42yM5CEQ7Q26p87
=MvU4
-----END PGP SIGNATURE-----

--ZmZU9S7l/XJx5q9b--

Heiko Schlittermann <hs [at] schlittermann.de> wrote:

> Peter Eisentraut <peter_e [at] gmx.net> (Do 19 Mär 2009 13:45:38 CET):
> >
> > Vorneweg: in 8.3 geht es richtig.
> >
> > Das Problem ist aber, dass er den Index umbenannt hat und nicht den
> > Constraint. Der Index wurde ja automatisch als Implementierungsdetail=

> > des Constraints angelegt. Korrekt wäre also entweder das direkte
> > Umbenennen des Index zu verhindern, oder -- etwas menschenfreundliche=
r,
> > wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen=
..
> >
>
> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wäre
> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und da=
nn
> ein "ALTER TABLE <table> ADD <table_constraint>" ?

Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
innerhalb einer Transaktion...


Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082=B0, E 13.56889=
=B0

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas Kretschmer wrote:
> Heiko Schlittermann <hs [at] schlittermann.de> wrote:
>
>> Peter Eisentraut <peter_e [at] gmx.net> (Do 19 Mär 2009 13:45:38 CET):
>>> Vorneweg: in 8.3 geht es richtig.
>>>
>>> Das Problem ist aber, dass er den Index umbenannt hat und nicht den
>>> Constraint. Der Index wurde ja automatisch als Implementierungsdetail=

>>> des Constraints angelegt. Korrekt wäre also entweder das direkte
>>> Umbenennen des Index zu verhindern, oder -- etwas menschenfreundliche=
r,
>>> wie es 8.3 ja auch macht -- den Constraint mit dem Index anzugleichen=
..
>>>
>> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wär=
e
>> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und d=
ann
>> ein "ALTER TABLE <table> ADD <table_constraint>" ?
>
> Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
> innerhalb einer Transaktion...

Das geht zwar, ist aber nicht der Performance-Knaller. Die Möglichkeit,=

das direkt umzubennen, wäre schon schöner.

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Peter Eisentraut wrote:
>>> Da ein "ALTER CONSTRAINT xyz RENAME TO abc" nicht existiert (?), wä=
re
>>> der offizielle Weg ein "ALTER TABLE <table> DROP CONSTRAINT xyz" und
>>> dann
>>> ein "ALTER TABLE <table> ADD <table_constraint>" ?
>>
>> Jo. Und alles schön in einer Transaktion, denn PG kann auch DDL
>> innerhalb einer Transaktion...
>
> Das geht zwar, ist aber nicht der Performance-Knaller. Die Möglichkei=
t,
> das direkt umzubennen, wäre schon schöner.

Stand auch schon in der TODO-Liste.


--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.o=
rg)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein

Andreas Kretschmer schrieb:
> ich leite hier mal was rein. Ich habe mal geschaut, was in pg_constraint
> und was in pg_class steht, und ich pg_constraint ist das offensichtlich
> falsch, also ich würde es als Bug sehen. Was meint ihr?
>
> (Problem nachvollzogen mit 8.1.4)

Das Problem tritt auch in 8.2.13 auf, nicht aber in 8.3.5.

Es handelt sich wohl um Bug #3854, behoben hier:
http://archives.postgresql.org/pgsql-committers/2008-01/msg0 0241.php

Vielleicht ein gutes Argument, auf 8.3 zu gehen, Suse hin, Suse her.

Liebe Grüße,
Laurenz Albe

--
Sent via pgsql-de-allgemein mailing list (pgsql-de-allgemein [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-de-allgemein